COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002		Comments re: AAAI Paper
C00005 00003	∂13-Oct-80  1226	TOB  
C00016 ENDMK
C⊗;
	Comments re: AAAI Paper
Date: 18 May 1980 1603-PDT
From: CSD.LENAT
Subject: AAAI Papers
To: CSD.GREINER

Very few were accepted (about one in four), including only some of the
program committee's papers.  Ours was accepted, however, in the "clearly
accept" category, of which there were surprisingly few examples.  Most
of the ones we finally accepted were originally calssified "good but not great".
I neglected to find out about (and didn't review) any other "local" papers,
so I don't know how Dave, Mike, etc. fared.  Brachman's repr. paper was
rejected (he was on the committee, incidentally) as insubstantive.  The
experience was a good one, overall; we got everything done in about 9
solid hours of work.   Woody Bledsoe will be staying over to meet with me
some tomorrow; I'll look around for you if you're interested.

Doug
-------

Mailed to LENAT@SUMEX (CC Hazen) 17:23 26-June
Doug:
	A copy of the paper was put in your mailbox, identical to the one on
Marion's desk. (Yes, both have lines drawn in...)
If you want to change the document, you'll probably want to use the
Window Edge command, typing (to Bravo) "WE10<esc>" -- this moves the screen
over to see the text.
(The file is <GREINER>RLL>AAAI1.BRAVO -- same password as usual.
Note the AAAI.BRAVO paper has NOT been kept up to date with the corrections.)
	Things to consider deleting, if space gets tight:
1. Subtitles
2. Whole Mary example - its more trouble than its worth, especially as it's wrong.
3. Semantics part -- especially the footnote. (Not that it's uninterested, but at
	$100/page, ....)
4. Part of the applications - where we assert that xxx is considering using RLL.
	[We should add in Larry's eventual work, don't you think?]

	I might meander it in the afternoon -- 
Russ
∂13-Oct-80  1226	TOB  
To:   ROD, DLO, BIS, SL
Bruce
That's an excellent letter.  Thanks for the support.
Tom


 ∂13-Oct-80  0155	BULLOCK at USC-ECL 	SAIL/MACLISP image processing software  
Date: 13 OCT 1980 0154-PDT
From: BULLOCK at USC-ECL
Subject: SAIL/MACLISP image processing software
To:   Druffel at ISI
cc:   tob at SAIL, bullock

I have been talking to Tom Binford lately about getting a copy of the
MACLISP based software kernel that he has been developing for image
understanding work.  I mentioned to Tom that I would send you a
note letting you know of our interest in using some of the 
you have supported.

Put simply, our work has undergone a long process of evolution.  In 1973 our
first scene analysis software package was implemented in LISP 1.6 and was
used to support work on rule based control structures for scene analysis
for several years on an AFOSR grant.  With the change in funding policy
about that time to emphasize work more directly related to military 
applications, the main line of our activity shifted from general system
investigations to applied work on  problems like target cueing and image
based terminal navigation.  Although I built one system for texture
analysis in SAIL while I was at Stanford during this
period, most of the systems we built from then on were in FORTRAN.  The shift
to FORTRAN was more practical than scinentific and had to do with 
compatability with funder supported computers and better availability of
programmers.  Starting about two years ago there was a new move
towards systems that for  the first time were fairly
complex and some were even rule based (again!) at the control level.  This
new generation was enough to justify finally dumping FORTRAN and trying
a switch to another language.  For a number of resons, Pascal was
chosen.  Several systems, including one with a rule based interpreter,
were implemented on both the PDP-10 and on the VAX.   For a number of reasons,
some of the most important involving memory management and automatic
garbage collection, Pascal proved to be a poor implementation language both
for image analysis software and rule based systems.  This brings us up to
about the current point in time.  A number of other languages have been
evaluated.  For straight image processing one of the best seems to be "C".
The situation is now more complex however, because for the first time
we are planning the construction of systems that have a much greater
demand for rule based/kbs components.  For example, in the case of
smart weapons this is especially true.  Independently of our image based
work we have been using Interlisp for some KBS application studies
envolving EMYCIN and some systems of our own.  Both folklore and some
experiments of our own have shown that Interlisp is certainly
not the common denominator link between AI/KBS/and IU that one might hope
for.  At the same time as our experience with KBS systems such
as EMYCIN has increased and our application interests have become more
specialized and complex we have realized that we will probably have
to do alot of our own system crafting to get
what we really wnat.  Thus, except for some of the new tools like RLL,
there is no strong reason to stick with Interlisp if we are not going
to use a canned system
like EMYCIN.  

All of this finally brings us to Tom's system.  Here it looks like we
can build the type of complex image analysis system we need, with
compatability with rule based systems all in one environment.  The kernel
operations in his system will probably allow us to go off in our slightly
different direction of hybrid IU/KBS systems but with a good IU starting
point.  Also, unlike 1973 when we were apushing to
keep working in LISP 1.6 with little success, the mood has changed
significantly, as you are well aware.  I think we can make (and probably
will) arguments that because of the advancement in LISP implementations
that emphasize efficiency and hardware such as the
LISP machine movements and VHSIC technology that it is also "practical"
for us to consider a major reorientation and emphasis to LISP based
software.

So, to bring this long story to a close.  For the many
reasons outlined above, we are seriously interested in a LISP based
system for our future work.  At the same time Tom's system looks to
have excellent ppossibilities
for what we want.  The implementation looks to be one of the best, system-wise,
around and the results from his work based on the software are very impressive.
We have expressed our interest to Tom and look forward to acquiring the
parts of his system that would be needed for our work.  If such a transfer
is successful, I will keep you posted of our progress.  We will also
be happy to acknowledge the source of the kernel in terms of Tom, 
Stanford, and DARPA.

Bruce Bullock.
-------